1. Field of the Invention
The subject invention relates generally to data processing systems and more particularly to a method and apparatus for marshalling data for transmission across an interface.
2. Description of Related Art
In the present state of the art, data is located everywhere: on mainframe servers, on PC desktops, on the web. Data resides in these environments in many different formats: relational and non-relational database management systems, ISAM files, e-mail, spreadsheets, audio, video, real time data feeds for news and stock, CAD/CAM systems, and so on.
With today""s tools and software technology, there is increasing pressure to provide access to this diverse data from multiple clients using standard interfaces, without moving the data from its origin. Businesses need to build solutions that span desktops, servers, and the Internet. In addition, the end user wants to access this data in the same way, regardless of the language used.
In order to facilitate access to structured and unstructured data in such diverse locations, Microsoft Corporation has developed a software interface specification known as OLE DB. OLE DB particularly provides a set of Component Object Model (COM) interfaces. According to OLE DB, data xe2x80x9cprovidersxe2x80x9d are employed to expose data stored as OLE DB compliant data sources so as to allow access to them by OLE DB data xe2x80x9cconsumersxe2x80x9d.
One type of data provider wherein the subject invention finds use may be viewed as a two-tiered application consisting essentially of two main components denoted the xe2x80x9cclientxe2x80x9d and the xe2x80x9cserverxe2x80x9d, which communicate with one another across a TCP/IP connection. The client sends messages called xe2x80x9crequestsxe2x80x9d across the connection to the server, and the server returns messages called xe2x80x9cresultsxe2x80x9d across the connection to the client. Requests and results consist of strings of bytes.
Client data is stored in PC format, which means that alpha data is encoded in ASCII characters and integers are stored with their bytes in reverse order (a characteristic of the Intel processors that are used on PC""s). The format of data on the host (server) is typically quite different. For example, alpha data on the host may be encoded in EBCDIC and integers may be stored with their bytes in normal order. Such encoding and storage is employed for example in Clearpath and A-Series environments present on computer systems manufactured by Unysis Corp., Blue Bell, Pa. Because of such differences between client and server data, the format of all data to be sent in requests by the client to the server must first be reformatted appropriately.
Client data is also organized in complex data structures often involving disconnected data located by pointers (memory addresses). Such data cannot simply be sent xe2x80x9cas-isxe2x80x9d to the server since the pointers point into the client""s memory space and would be meaningless in the host environment. At the very least, the memory addresses must first be converted to relative references such that the server can use them. Also, each item must be converted to the appropriate host format, and the structures must be reorganized in a buffer as a single string of bytes. The process by which all of this is accomplished is known as xe2x80x9cmarshallingxe2x80x9d, and the buffer used is referred to as the xe2x80x9crequest bufferxe2x80x9d. The marshalling technique wherein the preferred embodiment of this invention finds application involves providing a serial string of data structures called xe2x80x9cchunksxe2x80x9d wherein it is desired to maintain information in one chunk as to the location of a subsequent chunk.
A number of problems arise when designing object-oriented program code to marshal such request messages. A first problem is that, in allocating a new chunk, the request buffer might have to be resized, which could, and likely would, cause the buffer to be moved to a new location in memory. Thus, conventional pointers (absolute memory addresses) cannot be used to reference subsequent chunks. A second problem is how to avoid consuming large amounts of memory on the stack when objects representing the data chunks are instantiated. As known to those skilled in the art, the xe2x80x9cstackxe2x80x9d is an area of memory designated to hold data required by functions of the program.
According to the invention, chunks in a request buffer are referenced by the marshalling code without pointers. This approach is implemented by using objects to represent the various data structures or xe2x80x9cchunksxe2x80x9d in the request message, which objects contain only (1) an offset representing the offset of a particular data structure from the start of a message and (2) a pointer to a request object. The request object, which represents the message as a whole, includes methods for reformatting data to server-compatible format. Since the objects representing the data structures need only include an offset and a pointer, they consume very little stack memory when instantiated.
Thus, according to one aspect of the invention a request message is formed by a method comprising the steps of: representing each of a plurality of data chunks to be stored in the message by a respective chunk object; declaring each of the chunk objects as a variable on the stack; storing a first data chunk in a first area of the message; storing a second data chunk in a second area of said message; and employing the chunk object representing the first data chunk to locate the first data chunk in subsequent steps. Such subsequent steps may include the loading into the first chunk of an offset representing a location in the second chunk. Thus, an offset stored on the stack is used to locate a previous chunk in order to store in that previous chunk an offset value, instead of a pointer, where the offset value represents an offset from the start of the message.
Various objects, features and advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only the preferred embodiment of the invention, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive, and what is intended to be protected by Letters Patent is set forth in the appended claims. The present invention will become apparent when taken in conjunction with the following description and attached drawings, wherein like characters indicate like parts, and which drawings form a part of this application.